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ABSTRACT 



• In this paper a smooth program is defined to be one which is go to- 
free in the sense that it can be represented by a flowchart consisting only 
of concatenation, alternation, and iteration elements ♦ Three methods of 
eliminating the go to statement from a program have been proposed: 1) 
the introduction of additional Boolean variables or the equivalent recom- 
putation of certain quantities in the program, 2) the use of recursive 
procedure calls, and 3) replacement of the go to statement by a restricted 
form 'of the go to such as the exit or leave statement. We show that only 
the first of these is capable of transforming a non-smooth program into a 
smooth one s since strict application of the recursive procedure method 
requires the use of a so-called "null procedure" which is in fact also a 
restricted form of the go to . 
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I. Introduction 

In [1] Bohra and Jacopini consider the class of programs that can be 
represented by flow charts consisui: ; g of connections of computational and 
decision nodes. They assert that there exist flow charts which cannot be 
transformed directly into equivalent flowcharts consisting only of the 
flowchart elements tt, A , and ft, representing concatenation, alternation, 
and iteration respectively. If, however, additional Boolean variables 
may be introduced into the program, then any flowchart may be transformed 
into an equivalent flowchart consisting only of it, A, and.fi flowchart 
elements. In [2], Cooper showed', that the Boolean variables can be intro- 
duced in such a way as to simulate a location counter, yielding a trivial 
transformation of any flowchart into it, A, and a- single Q element. Bruno 
and Steiglitz [3] call a flowchart in tt, A, Q form a D-chart (after 
DijksU'a [4]) and give a formal proof of the existence of a flowchart 
which is not a D-chart, but whith can be transformed into a D-chart by 
the addition of Boolean variables or by recomputation of certain quantities 
in the program. We shall call a program representable by a -D-chart a 
smooth program and a language capable of expressing only smooth programs 
a smooth language . 

Knuth and Floyd [5] indicate the existence of two additional methods 
of eliminating go to statements from a program, namely the use of recursive 
procedure calls and the introduction of a restricted form of the go to such 
as the exit statement, which causes a premature exit from an iteration. They 
seem to suggest that the procedure call method is capable of transforming a 
non-smooth program into a smooth one. In fact, however, the recursive 
procedure method requires the introduction of a so-called "null procedure 11 
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which is different from all other procedures, including the go to procedure, 
in that it does not return to its point of invocation, but rather jumps to 
the end of the program. In ALGOL 60 [6] this null procedure can only be 
written as a procedure containing a go to statement* Therefore, we con- 
clude that the null procedure is actually a restricted form of the go to 
and that it is specifically the go to statement, not the procedure call 
mechanism, which makes ALGOL 60 a non-smooth language 



II. Definitions 

We begin by considering flowcharts which consist of tt (concatenation) 

r 

and A (alternation) only. Such flowcharts are series-parallel networks. 
They can arise from a block structured language such as ALGOL 60 by re- 
stricting the admissible statement types to computational and decision 
statements. Procedure invocation may also be admitted, provided the depth 
of recursion is bounded. 

Iteration statements may be mapped in terms of recursive procedure 
calls? directly. For instance in pseudo-ALGOL 60 

for c do L:S; 
can be rewritten 

procedure L; if_b then begin S; j ;L end; 
• i; L; 

where i, j, and b are the initialize, increment, and test components of c 
respectively. Thus programs containing iteration statements can be decomposed 
into tt and A without introduction of additional Boolean variables provided 
the iterative loops are rewritten as recursive procedure calls. Alternatively 
if Bohm and Jacopini's £2 (iteration) flowchart element is also allowed it is 
possible to flowchart iterative statements diredtly. We now make the following 
definitions: 

Definition 1 . A smooth program is one which can be decomposed into 
the flowchart elements tt (concatenation), A (alternation), and Q (iteration) 
without the introduction of additional Boolean variables. More briefly a 
smooth program is one whose flowchart is a D-chart. 

The concept may be related to work in the area of compiler design if we 
introduce the interval concept* as defined by Cocke [7] and Allen [8]. They 
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define an interval as a maximal single entry subgraph of a flowchart, such 
that all cyclic paths pass through the entry node. This leads to the following 
recursive definition: ' 

Definition 2^ A single computational or. decision node is a smooth 
interval . A two-terminal network of smooth intervals is a smooth interval if 
it satisfies the following restrictions: 1) the cyclic portion must be 
a series-parallel network leading from the entry nod* hack to the entry 
node and 2) the acyclic portion must be a series-parallel network. 

Definition 1*_. A smooth program is a smooth interval. 

Definition 3._ A smooth language is a programming language which can 
express only smooth programs 
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III. The Recursive Procedure Method 

Since Bruno and Steiglitz have shown, that not all flowcharts are D-charts, 

» 

the class of smooth programs must be a proper subclass of the class of all 
programs. Moreover, as we have noted, ALGOL 60 deprived of its go to state- 
ment is a smooth language, and we should therefore be able to conclude that 
not all ALGOL 60 programs can be written without the use of the go to state- 
ment. This conclusion is apparently contradicted by Knuth and Floyd when 
they indicate that go to statements can be replaced in ALGOL 60 by procedure 
calls and, in fact, that 'go to' is in some sense a special case of the 
procedure calling mechanism." As we shall see, this apparent contradiction 
arises because 1) they fail to point out that the null procedure is actually 
a-res.tricted form of the go to , and 2) they do not distinguish carefully 
between programs which are go to- free because they are smooth and those 
which are go to- free because they are non-smooth but happen to employ some 
restricted form of the go to . 

In replacing go to statements by procedure calls, Knuth and Floyd 
begin by labelling each statement of the program. Then they replace each 
L:S; 

by 

procedure L; begin S; L' end 

where L' is the successor of L. In the case of the go to statement they 
replace 

L: go to L* ; 

by 

procedure L; L* ; 

The composite statements of ALGOL 60 are not mentioned in this context 
by Knuth and Floyd. It does no violence to their analysis to specify that 
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1) L: if b then LT: ST else LF: SF; 
be replaced by 

procedure L; begin if b then LT else LF; l 1 end 

that 

2) L: for c do LG: SG; 
be replaced by 

procedure L; begin for c d£ LG; L 1 end 

that 

3) L: begin '[declarations; ] LG:SG; . . , end 
be replaced by 

procedure L; begin [declarations;] LG; L f end 
and finally that 1 

4) the governed statements of tin decision and iteration statements as well 

as the last statements in compound statements and blocks be replaced simply by: 
procedure L; S; 

since in all these cases the successor is already specified by the containing 
statement. Knuth and Floyd conclude the exposition of their technique by 
stating "The program ends by calling a null procedure # V 

To see why this technique merely replaces the go to statement by an 
equivalent construct, namely the null procedure, we will apply the technique 
to a program already discussed by Knuth and Floyd. We will treat it as a 
"complete" program, omitting declarations, input, and. output, in order to 
focus attention on the control flow. The examole program, augumented with 
labels as. required by the technique, is: 
begin 

LI: for i:=l step 1 until n do 
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L2: if A[i]=x then L3: go to found; 
L4: not found: n:=i; L5: A[i]:«x; L6: B[i]«0; 
L7: found: B[i] :=B[i]+l; 

The flow chart for this program is: 
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i:=l 








If we" apply the stated rules to the example, program the following procedures 
are obtained. 

procedure LI; begin for 1:=1 step 1 u ntil n 

do L2; L4 end 
procedure L2t if A[i]=x then L3; 
procedure L3; L7; 
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procedure L4; begin n:=i; L5 end 
procedure L5; begin A[i];=x; L6 end 
procedure L6; begin B[i]:=0; L7 end 
procedure L7: begin B[i] :=B [i]+l; null end 

where we include the call on "null" in procedure L7 because statement L7 
concludes the program. 

The flowcharts of the a^ve procedures are 



LI: 




i:=i+l 



Y 



L4 





L3: 



L7 



Substituting each at its point of invocation yields: * 



i:=l 


> 






B[i]: = B[i]+1 



1 null 



< i>n? >-g~ X A ^ = * ? > Jj - ^ E 



=1+1 



This flowchart is smooth, but does not represent the program because 
it does not show that the null procedure fails to return control to its 
point* of invocation, but instead jumps to the end of the program. In 
ALGOL 60, a procedure can do this only by executing a go to statement. 

Knuth and Floyd do give a smooth program using recursive procedure 
calls which is equivalent to their original non-smooth program: 

p rocedure find; 
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_if i > n then begin n:=i; A[i]:=x; B [i] :=0 
end ; 

else if A[i] t x then 

begin find end ; 

i:=l; find: B[i],: = B[i]+1; 

They are able to do this only because of the simplicity "of their original 
example. If, for example, we replace the statement L6 of their example by 
the semantically equivalent sequence: 

L6: B[i]:=l; go to L8; 
where L8 is a label placed on the end of the original program, their ad hoc 
transformation would no longer apply. 
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IV. The ex *t Statement 



Knuth and Floyd suggest that a third way of writing their example pro- 
gram is with a special repeat statement arid a restricted form of the go to 
called an exit statement. In this form, their example becomes: 
begin i:=l; 

repeat begin 

while a ^ u do If A[ij=x then exit else i:=i+l; 
n:=i; A[i]:*x; B[i]:«0; exit 

end ; 

B[iJ: «= B[i]+1; 

end ; 

The flowchart of this example is: 



i:-il 



repeat 



exit 



< 5 




A[i]=x? > N > | i:-i+l 



n:=i 



A[i]:=x 



B[i]:=0 



B[i]: = B[i]+1 
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This flowchart is clearly equivalent to the original* 

Another restricted form of the go to is found in the go to-free 
language BLISS [9] where the construct: leave- <label> with <expression> 
serves this purpose. This brings out the fact that the mere absence of the 
go to statement does not insure the smoothness of a programming language. 
On the other hand tKe absence of convenient block structuring features in 
FORTRAN would make the writing of ever, a smooth program in GO TO-less FORTRAN 
somewhat awkward ♦ 



V, Conclusions 

In this paper we have shown that the recursive procedure method proposed 
by Knuth and Floyd does not, as they suggest, transform a non-smooth program 
into a smooth one. Instead it merely replaces the go to statement by a re- 
stricted form of the go to , namely the null procedure. We have seen that 
ALGOL 60 without the go to statement is a smooth language whether invocation 
of non-null procedures is allowed or not. Therefore wp are left with Bohm 
and Jacopini f s original result, namely that in general the transformation of 
non-smooth programs into smooth ones requires the introduction of additional 
variables or the equivalent recomputation of some quantities in the program. 

It should be clear from the discussion that smoothness is not a property 

♦ 

of the algorithm being implemented, but of the program which implements the 
algorithm. Whether it: is desirable to retain, restrict, or eliminate the 
go to statement is a question of esthetics, since go to statements occurring 
in a program can always be replaced by additional code. It seems to us that 
a reasonable case has been made by Wulf for the replacement of the arbitrary 
go to by a restricted form, such as the leave construct of BLISS. Perhaps 
the term quasi-smooth could be used for non-smooth programs and languages 

using a restricted form, of the go to . 

. . v 

It should be possible^ to, find a use for the concept of the smooth pro- 
gram as a tool in the analysis of programs. One such application, to pro- 
gram analysis for parallel execution, has already been found and will be re- 
ported in a forthcoming paper. Other applications in the area of compiler 
optimization are being sought at the present time. Observations by other re- 
cent workers in this field, especially the remark by Lowry and Medlock [10] 
that most loops in FORTRAN programs are single entry loops, give us reason to 



believe that the class of smooth programs includes a substantial subset o 
useful programs. We believe therefore that the class of smooth languages 
should also be of practical interest. 
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